Pruning Contracts with Rosette

Contracts are a pragmatic tool for managing software systems, but programs using contracts suffer runtime overhead. If this overhead becomes a performance bottleneck, programmers must manually edit or remove their contracts. This is no good. Rather, the contracts should identify their own inefficiencies and remove unnecessary dynamic checks. Implementing contracts with Rosette is a promising way to build such self-aware contracts. 1. The Trouble with Contracts Racket’s higher-order contracts [3] are an expressive and easy-touse specification language. Any programmer can design a contract, as the language for building contracts is essentially Racket. For example, the following program defines a function even++ that accepts only even numbers and returns only odd numbers. The contract combinator -> specifies the behavior of even++ using the predicates even? and odd?. #lang racket/base (require racket/contract) (define (even? x) (zero? (modulo x 2))) (define (odd? x) (even? (+ x 1))) (define/contract (even++ n) (-> even? odd?) (+ n 1)) Beyond Racket’s particular implementation, this idea of Design by Contract [4] scales to large programs [1] and complex specifications [2]. The trouble with a guarded function such as even++ is that each one call to the function triggers three function calls. An application (even++ 4) must first assert that 4 is an even number, then apply even++, and finally assert that 5 is an odd number. Checking the precondition even? is a necessary overhead, but clearly the postcondition odd? will never fail. In other words, (even? v) implies (odd? (even++ v)) for any possible input v. Contracts on higher-order functions may lead to even worse overhead. To illustrate the potential issue, consider an identity function specified over functions similar to even++: (define/contract (identity f) (-> (-> even? odd?) (-> even? odd?)) f) The application (identity even++) consequently applies the contract (-> even? odd?) twice more to even++. Calling ((identity even++) 4) asserts that 4 is an even number three times. In more realistic programs, similar higher-order contracts have led to order-of-magnitude [10] and exponential [9] performance overhead.